04/19/19 10:51
When refactoring code, there's a rule to either change the structure or change the functionality, but never both at the same time.
This applies to other areas of life.
When modifying systems (especially complex ones), holding the outputs (the expected functionality) constant acts as a set of test cases.
Likewise, the structure constrains what functionality is achievable.
When you want to add functionality not possible with the current structure, you need to change the structure
first.
The tendency is to want to do both at the same time, but changing the structure of a system will invariable break some existing functionality. By first changing the structure, you can more clearly assess what functionality will break, and decide if that is an acceptable tradeoff.
Related: Design.